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(54) Precede de paiement dans une application telematique et dispositif de mise en oeuvre de 
ce precede 



(57) La presente invention conceme un proc6d6 de 
paiement, dans une application tdlematique, de som- 
mes dues par un utilisateur pour des prestations deli- 
vrees par un serveur d'application. 

L'invention concerne egalement un dispositif de mi- 
se en oeuvre de ce precede qui permet I'anonymat. Ce 
dispositif comprend un kiosque (k), au moins un serveur 
d'application (Ai) et au moins un utilisateur (Uj). Le ser- 
veur d'application n'a pas a connaitre I'identite de I'utili- 
sateur puisque c'est le kiosque qui gere le compte de 
I'utilisateur. De plus le kiosque n'est pas capable de re- 
constituer les transactions effectu^es par un tel utilisa- 
teur aupr^s de tel serveur d'application, grace k une 
structure particuliere de cheques electroniques. 
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Description 

Domaine technique 

la presente invention concerne un procede de paie- 
nnent dans une application telematique, et un dispositif 
de mise en oeuvre de ce procede. 

Etat de la technique ant^fieure 

Dans une application telematique, un utilisateur doit 
payer les prestations que lui delivre un serveur d'appli- 
cation. Des fornnules d'abonnement indifferencie sont 
trop simplistes pour etre satisfaisantes a cat egard et ne 
permettent pas de refleter la valeur des informations 
fournies a un utilisateur pour une transaction particulle- 
re. Par ailleurs, ('obligation pour un utilisateur d'avoir ^ 
faire une demarche d'abonnement aupr6s de chaque 
serveur consulte ne favorise pas la spontaneite de ses 
consommations. 

L' infrastructure de paiement ne doit cependant pas 
etre trop couteuse, eu egard au faible cout des presta- 
tions generalement dellvrees. Cecl ecarte des solutions 
ou le serveur facturera it directement son utilisateur (pro- 
cedure de paiement ou telepaiement classique). Ceci 
explique I'interet des "serveurs de paiement", ou "kios- 
ques", auxquels les serveurs d'application sous-traitent 
les operations de paiement, puis de recouvrement des 
sommes dues. Ce genre de solutions permet a un utili- 
sateur de se connecter a un serveur d'application sans 
qu'il ait d'abonnement prealable pour ce serveur, et per- 
met aussi de rendre I'utilisateur anonyme par rapport a 
ce serveur : le serveur d'application n'a plus a avoir d'in- 
formation sur I'identite de I'utilisateur 

Un exemple de kiosque se rencontre notamment 
pour le Minitel (marque deposee) et les numeros d'appel 
3615 et 3614. Le kiosque fonctionne alors ^ la duree : 
le kiosque multiplie la duree de la connexion utilisateur/ 
serveur par le taux du palier, et impute la somme ainsi 
obtenue a I'utilisateur 

Pour plus desouplesse, la taxation peut etre definie 
suivant la valeur de I'information fournie par le serveur 
d'application a I'utilisateur Pour s'assurer de I'accord de 
Tulilisateur, la procedure est alors la suivante : 

le serveur d'application demande ^ Tutilisateur une 
somme determin^e ; 

I'utilisateur, s'il est d'accord, demande au kiosque 
de payer cette somme au serveur d'application ; 
le kiosque debite le compte de Tutilisateur de cette 
somme et credite celui du serveur d'application de 
celle-ci ; 

le kiosque renvoie un acquittement au serveur d'ap- 
plication, directement ou par I'intermediaire de I'uti- 
lisateur 

Mais, avec cette approche du paiement, apparait 
un probleme d'anonymat par rapport au kiosque qui, de 



par ses fonctions, connait toutes les pratiques et habi- 
tudes des utilisateurs. Meme si le kiosque est exploite 
par une organisation institutionnelle, un probleme de 
manque d'anonymat, et done d'atteinte a la vie privee 
5 de I'individu, se pose alors. 

Un document de I'art anterieur intitule "Untraceable 
Electronic Cash" de David Chaum, Amos Fiat et Moni 
Naor (Proceedings of Crypto'88, Lectures Notes in 
Computer Science, volume 403, Springer Verlag, pages 
10 319 a 327) concerne une solution de paiement anony- 
me. 

Le principe de ce paiement est alors le suivant : 

un utilisateur achete de la monnaie electronique a 
IS sa banque ; 

cet utilisateur depense cette monnaie chez des 
commergants ; 

chaque commer^ant est collects par la banque. 

20 Plus precisement, ces echanges peuvent etre de- 
crits de la fa^on suivante : le mot "piece" designe une 
donnee emise par la banque, comprenant une signature 
electronique et ayant une valeur fixee (1 franc par exem- 
ple). 

25 Pour le chargement ; 

1- L'utilisateur demande k la banque une pi^ce de 
1 franc. 

2- La banque debite le compte de I'utilisateur de 1 
30 franc ; la banque envoie a I'utilisateur la piece. 

Ces deux etapes peuvent etre repetees plusieurs fois, 
pour avoir plusieurs pieces. 
Pour le paiement on a : 

35 

3- Le commergant demande ^ I'utilisateur m francs. 

4- L'utilisateur envoie au commergant m pieces. 

5- Le commergant verifie les pieces et stocke cel- 
les-ci. 

40 

Ulterleurement on a la collecte suivante : 

6- le commergant transmet ^ la banque les pieces 
stockees ; 

45 7- la banque v6rifie les pieces, cumule les montants 
et paye le commergant. 

Pour le paiement, deux cas sont decrits dans ce do- 
cument de I'art anterieur : 

50 

en "Off-Line" : le commergant et l'utilisateur, lors de 
la transaction ne sont pas en ligne avec la banque. 
Pour expliquer comment le commergant peut s'as- 
surer que la piece electronique n'a pas deja ete uti- 
55 lisee par l'utilisateur, ou dupliqu6e par le commer- 
gant, deux mdthodes sont propos6es : 

o une piece est utilisable une seule fois, sous pei- 
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Les transactions ont une valeur inconnue a priori, 
et done la banque donne a Tutilisateur des pieces d'un 
montant predetermine, quitte pour I'utilisateur d'en utili- 
ser le nombre qu'il faut pour payer le commer^ant. Une 
telle procedure est done lourde et presente un probleme 
d'appoint. 

Cette solution presente done de nombreuses diffe- 
rences avec un syst^me utillsant un kiosque. 

Dans cette solution, il faut constituer un fichier de 
toutes les pieces collect6es, depuis la creation du sys- 
teme de paiement electronique, d'ou une lourdeur tr^s 
grande. 

Une demande de brevet WO-A-95/0441 7 decrit des 
moyens cryptographiques utilises par trois types de par- 
ticipants dans un systeme electronique permettant un 
transfert protege d' informations certifiees. Ceci est rea- 
lise par un protocole a signature aveugle en combinat- 
son avec un protocole de test. Le protocole ^ signature 
aveugle permet a la partie qui certifie de coder les don- 
nees en informations certifiees qu'il fournit a une partie 
qui regoit, de maniere telle qu'elles ne peuvent pas etre 
alterees ou modifiees par cette partie qui regoit. Le pro- 
tocole de test permet aux parties de prouver differentes 
caraeteristiques concernant les donnees codees dans 
leurs informations certifiees. 

Cette demande de brevet rappelle I'etat de I'art con- 
nu, notamment le concept de signature aveugle du k 
Chaum protege par le brevet US-A-4 759 063. Celui-ci 
permet d'obtenir et d'utiliser une information signee par 
une autorit6, cette information etant connue de I'utilisa- 
teur qui la demande, mais pas de I'autorite. Si cette in- 
formation represente une piece electronique, elle doit 
etre utilisee seulemenl une fois. Rien ne peut empecher 
de dupliquer des donnees informatiques ; il faut done 
que la reutilisation d'une piece electronique deja utilisee 
permette de reveler I'idenlite de I'utilisateur qui a f raude. 
Un protocole permettant de signer de fagon aveugle une 
information doit done contenir de quoi rep^rer Tutilisa- 
teur s'il fraude. Cette information, si elle contient bien 
de quoi reperer I'utilisateur a qui elle est donnee, est 



souvent dite "bien formee" dans I'etat de I'art. Or "aveu- 
glement" et "bien formee" sont antinomiques a priori. 
Une methode dite "cut and choose" permet de resoudre 
cette apparente contradiction : ne pas connaitre une in- 
formation tout en etant sur qu'elle possede une certaine 
propriete. 

Dans ladite demande de brevet est 6nonce un "res- 
trictive blind signature scheme" plus performant que la 
methode "cut and choose" d6finie plus haut. L'informa- 
tion signee, appelee "credential" est constituee de fagon 
a n'etre utilisable qu'une fois. Cette information signee 
peut aussi etre combinee avec une quantite telle que le 
montant. Tout ceci est applicable a un systeme de paie- 
ment "off-line" de type piece ou cheque electronique. 

Dans le cas d'un paiement par pieces ou cheques, 
on a alors trois acteurs : la banque B, I'utilisateur U, le 
commergant (shop) S. U peut payer par exemple un 
journal chez un commergant S, mais U peut aussi payer 
un foumisseur d'informations S qu'il consulte avec son 
PC sur INTERNET. 

Dans le cas de pieces electroniques, il s'agit d'une 
transcription electronique des pieces ou billets utilises 
dans la vie de tous les jours. Les echanges entres ces 
differentes parties sont les suivants : 

0 Rechargement de U (son PC, ou sa carte) avec des 
pieces qu'il stocke en m^moire : cette procedure se 
passe entre U et B. Ces pieces ont une valeur fig6e, 
par exemple 1$. Le protocole permet de charger 
une telle piece, avec la propriete, expliquee plus 
haut, d'anonymat (signature aveugle), et de verifier 
qu'elles sont bien formees : elles contiennent I'iden- 
tite de U. La banque doit bien sur connaitre cette 
identification pour debiter le compte de U du mon- 
tant de pieces achetees par U. 

<» Paiement par U d'un commergant S : une fois que 
U possede des pieces, il peut les utiliser pour des 
achats. Le protocole est done une preuve de con- 
naissance non reutilisable que U a dans sa memoi- 
re les donnees relatives a une piece 1$. Le paie- 
ment est totalement deconnecte du rechargement, 
qui doit avoir ete fait avant, pour que U dispose du 
montant de pieces necessaires. Cette procedure ne 
fait intervenir que U et S. 

• Remise de S ^ B ; S a done accumule des pieces 
(ou plutot des preuves de connaissanee de pieces) 
qui lui ont 6t6 donnees par ses clients. Au moyen 
d'un protocole (non detaille dans WO-A-95/0441 7), 
il vide les pieces accumulees pour que B credite son 
compte d'un montant correspondant. La banque 
doit proceder k des controles de non reutilisation 
(egalement non detailles). Si elle retrouve pour la 
meme piece plusieurs utilisations (preuves de con- 
naissanee), alors un traitement simple permet de 
retrouver I'identite de U qui avait achete et depens6 
ces pieces. 

Dans le cas de cheques electroniques, il s'agit 



ne de reveler a la collecte une information per-, 
mettant a la banque d'identifier I'utilisateur 
malhonnete ; ceci est possible grace a une 
structure particuliere des donnees de la piece 
electronique, et ceci implique que la banque s 
conserve toutes les pieces deja collectees, 
o pour obtentr une securite physique, I'utilisateur 
utilise une carte k puce, objet inviolable, dont 
le comportement ne peut etre modifi6 par I'uti- 
lisateur, et qui ne reutilise jamais la meme io 
piece ; 

en "On-Line" : lors de la transaction entre le com- 
mergant et I'utilisateur, en 5, le commergant contac- 
te la banque pour savoir si la piece presentee n'a 
pas deja ete utilisee. La banque doit la aussi con- 
server toutes les pieces d6\k collectees. 
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d'une approche legerement differente de celle des pie- 
ces electron iques. Mais elle utilise des protocoles tres 
voisins. Elle est d'un emploi plus simple. En effet, les 
pieces ont une valeur fixe (1 $ par exemple). Pour payer 
par exennple 9$, il faut uttliser neuf pieces. Avec les che- 
ques, le nnontant est defini lors de Tutilisation de la piece. 
Dans Texemple defini ci-dessus U fera done un seul 
cheque de 9$. 

o U achete un cheque d'un montant maximum M. Ce 
montant M est insere dans les informations repre- 
sentant le cheque (analogue au cas des pieces). Le 
protocole permet de faire ce chargement de fagon 
tres voisine au cas d'une piece de montant M. M est 
soustrait du compte de U. 

o U utilise pour payer un montant m, demande par S, 
un cheque de montant maximum M > m. Le proto- 
cole est tr^s proche du paiement avec une piece, 
mais la preuve de connaissance comporte de plus 
le parametre m. 

» Remise par S des cheques regus (ou plutot des 
preuves de connaissance de ces cheques) a B : 
processus analogue au cas des pieces. 

o Un echange supplementaire doit avoir lieu entre U 
et B, pour que U se fasse rembourser sur son comp- 
te la difference M-m. 

Cette demande de brevet WO-A-95/04417 decrit 
aussi I'utllisation de modules "tamper resistant", ce qui 
permet de garantir que U ne pourra utiliser deux fois le 
meme cheque ou la meme piece, de par la constitution 
de la machine (carte a puce ou PC) contenant ces pie- 
ces ou cheques, ainsl que la creation de compte ano- 
nyme, qui consiste a convenir d'un pseudonyme entre 
U et B (U ne devoilant pas son identite a B). 

Par contre la presente invention a pour objet un pro- 
cede d'echanges entre un utilisateur, un kiosque et un 
serveur d'application, resolvant le probleme d'anony- 
mat. Get anonymat est relatif au kiosque et non aux re- 
seaux (11 peut y en avoir plusieurs) qui se trouvent entre 
les utilisateurs et les serveurs. Ces reseaux sont appe- 
les a connaitre les adresses reseau de ces differents 
acteurs. Ces adresses peuvent d'ailleurs varier : c'est 
par exemple le cas d'un utilisateur qui se deplace. 

Expose de I'lnvention 

La presente Invention concerne un precede de 
paiement, dans une application telematlque, de som- 
mes dues par un utilisateur pour des prestations deli- 
vrees par un serveur d'application, caracterise en ce 
qu'il comprend les etapes suivantes : 

ledit serveur d'application envoie audit utilisateur 
une demande de paiement pour une somme 
determinee ; 

ledit utilisateur demande k un serveur de paiement, 
ou kiosque, donne le paiement de ladite somme 



determinee ; 

ledit serveur de paiement debite le compte dudit uti- 
lisateur de ladite somme determinee, et envoie 
audit utilisateur un cheque electronique correspon- 
5 dant a la somme determinee ; 

ledit utilisateur verifle ce cheque electronique, le 
modlfie pour que le serveur de paiement ne le re- 
connaisse pas, et I'envoie audit serveur 
d'application ; 

10 - ledit serveur d'application verifiece cheque electro- 
nique et stocke celui-cl ; 

et en ce que, dans des etapes ulterieures : 

IS . ledit serveur d'application transmet audit serveur de 
paiement au molns un cheque electronique stocke ; 
ledit serveur de paiement verifie chacun des che- 
ques electroniques re9us et paye audit serveur 
d'application le montant cumule de ceux-ci. 

20 

Dans le contexte technique des reseaux telematl- 
ques et serveurs de paiement ou kiosques, le procede 
de invention concerne une organisation de la fonction 
paiement basee sur des "cheques electroniques" dont 
25 la constitution de principe est definie. Cette approche 
permet un anonymat complet des actions de 1' utilisateur. 

Un "cheque" d^signe un ensemble de donnees 
electroniques emises par un serveur de paiement. II 
comprend une signature electronique et a une valeur 
30 determinee. Avantageusement un cheque contient une 
information concernant son montant et sa date, ainsi 
qu'un alea. 

Avantageusement la verification de la septleme 
I'etape concerne la signature des cheques, la non-pre- 
35 sence d'un cheque identique dans le fichler des che- 
ques regjus et la mise ^ jour de ce fichier avec ce nou- 
veau cheque. 

Avantageusement, malgre les traitements preala- 
bles, les cheques re9us apres I'etape de transmission 
40 d'au molns un cheque electronique, stocke par le ser- 
veur d'application, au serveur de paiement ne peuvent 
etre correles avec ceux envoyes dans I'etape d'envoi 
d'un cheque electronique par le serveur de paiement a 
I'utlllsateur, grace a la modification de I'etape d'envoi du 
45 cheque au serveur d'application, ce qui permet de gar- 
der I'anonymat de I'utilisateur. 

Les serveurs d'application peuvent collecter leurs 
cheques avec une certaine periodicite, par exemple in- 
ferieure a la semaine. 
50 Dans une premiere variante le procede de I'lnven- 
tion permet de resoudre les litiges eventuels entre paie- 
ment et remise de I'information electronique, selon deux 
moyens, et cecl bien que I'anonymat soit une caracte- 
ristique importante d'un tel procede : 

55 

L'information envoyee par le serveur d'application 
a I'utilisateur peut etre chiffree. La cle de dechlffre- 
ment est calculee par le kiosque lors du debit du 
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compte de I'utilisateur et envoyee a I'utilisateur Le 
serveur d'application signe ce qu'il envoie a I'utili- 
sateur, ainsi paiement et remise sont synchronises. 
Ainsi le serveur d'application ne peut plus repudier 
son envoi a I'utilisateur pour etre paye par lui sans 
lui fournir de service, c'est-a-dire sans lui envoyer 
une information utilisable. II protege I'integrite dece 
qu'il envoie (pour eviter que I'utilisateur n'altere I'in- 
formation dans I'intention de se faire rembourser). 
Le kiosque est le "juge" qui, en cas de Ittige, dispose 
des elements cryptographiques irrefutables lui per- 
mettant de savoir qui est le fautif. 
La remise par le serveur d'application des informa- 
tions a I'utilisateur se fait apres reception du cheque 
de I'utilisateur, mais le serveur s'engage avant le 
paiement sur la remise de I'lnformation par une si- 
gnature electronique. Ceci resout tous les cas de 
fraude de I'utilisateur. Le serveur d'application ne 
s'engage sur I'lnformation qu'il va fournir a I'utilisa- 
teur, qu'apres le paiement, par une signature. 

Contrairement au systeme decrit le document de 
I'art anterieur cite plus haut, dans cette approche kios- 
que le chargement et le paiement sont lies, car ils se 
font en meme temps : I'utilisateur, le serveur d'applica- 
tion et le kiosque sont "On-Line". Ceci simpllfie le pro- 
bleme de la verification de la non duplication des pieces 
par I'utilisateur : un alea choisi par le sen/eur d'applica- 
tion empeche I'utilisateur de reutiliser des donn^es de 
signature du serveur d'application qu'il aurait obtenu 
auparavant. L'utilisateur connait le montant demande 
par le serveur d'application ; il n'y a plus de problemes 
d'appoint. 

Le probleme de duplication par le serveur d'appli- 
cation de cheques se resout en rajoutant au montant, 
un horodatage, controle par le kiosque lors de la tran- 
saction. Comme les pieces sont consommees juste 
apres avoir ete achetees par I'utilisateur du kiosque, 
alors il suffit pour le kiosque de tester les doublons sur 
une periode egale au temps separant deux collectes. 

L'invention concerne egalement un dispositif de mi- 
se en oeuvre de ce procede, dans lequel au moins un 
kiosque, au moins un serveur d'application sont en 
liaison avec au moins un utilisateur par I'lntermediaire 
d'un reseau de communication. Les techniques de si- 
gnature aveugle permettent de laisser apparents dans 
les informations signees le montant et la date, et ame- 
nent une simplification importante par rapport aux tech- 
niques habitueltes. 

Breve description des dessins 

Les figures 1 a 3 illustrent le procede de invention ; 
les figures 4 et 5 Illustrent deux procedes de Tart 
anterieur ; 

les figures 6 et 7 illustrent respectlvement deux va- 
riantes du precede de invention. 



Expose detaille de modes de realisation 

Le dispositif de mise en oeuvre du procede de l'in- 
vention, tel que represents sur la figure 1 comprend un 
5 kiosque K, des serveurs d'application A1 a Am, et des 
ulilisateurs Ul a Un tous relies a un reseau de commu- 
nication. 

Led it proc6d6 est un proced6 de paiement dans une 
application tel6matique, dans lequel I'anonymat de I'uti- 
10 lisateur vis-^-vis du kiosque est respecte. 

Si on designe par U un des utilisateurs, A un des 
serveurs d'application et K le kiosque, on peut definir 
I'anonymat par deux regies : 

J5 - regie 1 : le serveur d'application A ne doit pas con- 
naitre I'utilisateur U ; 

r6gle 2 : le kiosque K ne doit pas savofr que I'utili- 
sateur U utilise (ou a utitis6) le serveur A. 

20 Mais ceci ne doit pas empecher le serveur d'appli- 
cation d'etre paye pour les prestations qu'il effectue pour 
I'utilisateur. La regie 1 n'a bien sur pas de sens si I'ap- 
plication serveur requiert I'identite de I'utilisateur et si 
I'utilisateur fournit cette identite. Mais dans le cas le plus 

25 general, la regie 1 doit s'appliquer. La regie 2 permet de 
prot6ger la vie priv6e des clients. Elle doit etre entendue 
au sens que le kiosque ne doit avoir aucune possibilite 
pour reconstituer les identifiants des applications selec- 
tionn6es par les utilisateurs. 

30 On considere que I'utilisateur utilise un moyen de 
paiement non anonyme car, dans le cas contraire, I'ano- 
nymat des transactions utilisateur/serveur/kiosque est 
inherent au systeme de paiement utilise. 

Les cas couverts par l'invention sont done : 

35 

le paiement par carte bancaire ou carte 
d'abonnement ; 

le simple abonnement : I'utilisateur n'a, pour acce- 
der au kiosque, qu'un mot de passe qui lui a ete 
40 donne lors de son abonnement au kiosque. 

Lors d'une transaction, le kiosque va done connai- 
tre I'utilisateur et son identite idU, c'est-a-dire son nu- 
mero de carte bancaire ou son numero d'abonne a I'ope- 
45 rateur du kiosque. 

II existe alors diffSrents cas de raccordements : 

un premier cas se pr^sente lorsque la fonction pas- 
serelle u till sate urs/serveurs (concentration, adap- 
50 tation des transmissions et protocoles) est confon- 
due avec la fonction kiosque. Ce cas peut etre 
schematise : 

U-K-A 

55 Dans ce cas, la regie 2 ne peut etre satisfaite, puis- 
que le kiosque K doit 6tablir la connexion avec le 
serveur d'application A, done connaitre son 
identite ; 
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dans un second cas schematise : 
U-A-K 

Le serveur d'application doit elablir la connexion 
avec le ktosque, at si ceci n'inriplique pas que le kios- 
que connaisse le serveur d'application, alors cette 
solution de raccordement n'est pas incompatible 
avec la regie 2. De meme la regie 1 peut etre satis- 
falte, mais comme le serveur d'application se trouve 
entre Tutilisateur et le kiosque, 11 taut que les don- 
nees d'identite de I'utilisateur (idU) soient chiffrees 
entre I'utilisateur et le kiosque ; 
un troisieme cas peut etre schematise : 

^ A 



U 




A I'evidence, cette solution est compatible avec les 
regies 1 et 2. Cette solution n'implique pas deux 11- 
gnes de transmission differentes issues de Tutilisa- 
teur. Une meme liaison physique peut contenir plu- 
sieurs canaux, chacun avec des destinataires diffe- 
rents. De nombreux reseaux, avec les protocoles 
de transport adequats, offrent ces possibilites : 
Transpac (marque deposee), Itineris (marque de- 
posee) en France.... 

Dans la suite de la description on se place, a titre 
d'exemple, dans cette derniere hypothese de raccorde- 
ment. Le second cas conviendrait aussi, moyennant de 
respecter les conditions correspondantes. 

Comme reprdsente sur la figure 2 les echanges se- 
lon le procede de I'lnvention peuvent dtre decrits par la 
succession des etapes suivantes : 

1- Le serveur A envoie a I'utilisateur U une demande 
pour une certaine somme (bloc 11). 

2- L'utilisateur U demande au kiosque K cette som- 
me (bloc 12). 

3- Le ktosque K d6bite le compte de I'utilisateur U 
de cette somme : le kiosque K envoie k I'utilisateur 
U un cheque electronique de cette somme (bloc 
13). 

4- L'utilisateur U verifie ce cheque, le modifie pour 
que le serveur de paiement ne le reconnaisse pas 
et I'envoie au serveur d'application A (bloc 14). 

5- Le serveur A verifie et stocke ce cheque (bloc 
15). 

Ulterieurement (test 18) : 

6- Le serveur d'application A transmet au kiosque 



K les cheques stockes (bloc 16). 

7- Le kiosque K verifie les cheques, cumule les 

montants et paye le serveur A (bloc 17). 

5 Le mot "cheque electronique", par analogie avec un 
cheque classique, designe un ensemble de donnees 
6lectroniques ou numeriques emises par le kiosque, 
comprenant notamment une signature electronique. et 
ayant une valeur convenue. II constitue pour le serveur 

10 d'application une garantie de paiement. Le serveur A 
stocke celui-ci et presente au kiosque K, ulterieurement, 
pour etre paye a son tour. 

Le cheque est une signature par le kiosque du mon- 
tant m. Pour des problemes de rejeux il contient aussi 

15 un alea c qui est choisi par le serveur d'application et 
envoye a l'utilisateur dans I'etape 1. 

Si, dans les echanges represent^s k la figure 2, on 
utilise un alea c, un probl6me d'anonymat se pose car 
II devient possible au kiosque de relier, grace a cet atea 

20 c, I'echange de I'etape 2 entre l'utilisateur et le kiosque, 
et I'echange de I'etape 6 avec un cheque de meme mon- 
tant m et de meme alea. La regie 2 ne peut done plus 
etre satisfaite. En fait, I'informatlon genante pour I'ano- 
nymat est I'alea c : le montant m peut permettre de relier 

25 les etapes 2 et 6, mais en pratique, l'utilisateur peut frac- 
tionner son paiement en valeurs 6l6mentaires (comme 
quand on paye avec des pieces ou billets). Done le mon- 
tant m va correspondre k des montants pred^finis, et de 
nombreuses transactions auront le meme m. par exem- 

30 pie pour payer 11 francs, l'utilisateur peut demander au 
kiosque un cheque de 10 francs et un de 1 franc. 

Pour resoudre ce probleme, invention utilise done 
un mecanisme de signature aveugle, dont le principe 
est decrit dans I'article intitule "Blind Signatures for Un- 

35 traceable Payments" de David Chaum (Crypto'82, Ple- 
num Press, New- York, 1983, pages 199 a 203). Le me- 
canisme de invention peut etre repr^sent^ par le sche- 
ma illustre a la figure 3. Le montant m contient une in- 
formation sur le montant du cheque, et la date : cette 

40 derniere information permet au kiosque d'eviter des re- 
jeux par le serveur d'application de cheques deja 
utilises : le kiosque n'a pas a memoriser tous les che- 
ques deja utilises, mais simplemenl, par exemple, ceux 
de la semaine courante, si les serveurs d'application 

45 collectent leurs cheques par exemple, avec une perio- 
dicity inf6rieure k la semaine. Dans I'etape 7, la verifi- 
cation concerne done la signature Sig des cheques, la 
non presence d'un cheque identlque dans le fichier des 
cheques regus la semaine, et la mise a jour de ce fichier 

50 Plusieurs exemples de signatures aveugles ont ete 
developpes dans I'art anterieur. 

Un systeme dit RSA decrit notamment dans un ar- 
ticle intitule "A Method for Obtaining Digital Signatures 
and Public-Key Cryptosystems" (Communications of 

55 the ACM, fevrier 1 978, pages 1 20 ^ 1 26) et dans 'L'echo 
des recherches" n° 124, 2^"^® trimestre 1986, page 39, 
est un exemple type de systeme k cle publique. 

Les schemas de signature aveugle avec RSA sont 
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classiques. Les calculs se font dans Zn (entiers mcxdulo 
n). c est calcule par c = P(r).c', ou r est un alea preala- 
blement choisi par le dennandeur de la signature de I'uti- 
lisateur. P est la fonction publique inverse de Sig. 
D'apres les proprietes nnultiplicatives de RSA, Sig(c) = 
r.Sig(c') et done Sig(c') = Sig(c)/r. 

Mais dans ce schema, il n'est pas possible de com- 
biner une partie aveugle c et une partie m qui ne Test 
pas. 

Les adaptations au schema general ci-dessus sont 
done : 

pour le montant : avoir des cles RSA differentes 
pour differentes valeurs de cheques : par exemple 
franc, 5 francs, 10 francs... ; 
pour la date : le kiosque change period iquennent 
ces cl6s : toutes les semalnes dans I'exennple ci- 
dessus. 

Un article intitule "Efficient Identification and Signa- 
tures for Snnart Cards" de CP. Schnorr (Proceedings of 
Crypto'89, Lectures Notes in Computer Science, volu- 
me 435, Springer Verlag, pages 239 a 252) decrit un 
systeme de signature. 

On considere les notations suivantes : 

n nombre premier (512 bits) ; b^ , b2 element de Zn*. 
d'ordre q, grand ; 

s secret du kiosque, appartenant a Zn* ; 
P-, , p2 cles publiques du kiosque : pi= b^ ® 2-,= bg® ; 
h fonction de condensation, publique, a resultat 
dans Zq. Tous les calculs d'exponentiation sont faits 
modulo n ; les calculs de y, c, y', c' sont faits modulo 

q- 

Comme represents sur la figure 4 on peut utiliser le 
schema de Schnorr avec un g6n6rateur b dependant de 
m : b = b^ '^b2. Ce choix permet d'eviter certaines fai- 
blesses d'un choIx plus simple b = bi du fait que bP = 
( bi "ib2)P et trouver m' et p' tel que (b^ "^'b2)P' - bP est 
d'une difficulte identique au probleme du logarithme 
dans Zn. 

Pour effectuer la verification on effectue les calculs 
de b = bi "ib2 ; p = Pi "^P2 ; C = h(a,t', idA) ; le test bv' = 
t'p<='. 

Un article intitul6 "A Practical Zero-Knowledge Pro- 
tocol Fitted to Security Microprocessor Minimizing Both 
Transmission and Memory" de L.C. Guillou et J.J. Quis- 
quater ("Proceedings Eurocrypt' 88, Springer Verlag, 
Lecture Notes in Computer Sciences" volume 330 - 
1988 - pages 123-128) decrit un schema dit GQ base 
sur la difficulte de factoriser de grands entiers. 

On prend les hypotheses et notations classiques du 
schema GQ : 

n : grand nombre, produit de deux nombres pre- 
miers p et q. 

e : nombre premier entier (le calcul dans Zn des ra- 



cines e-iemes est possible si Ton connait p et q). 
g : est une fonction de Hashing, publique, a resultat 
dans Zn ; elle doit, pour eviter certaines possibilites 
d'attaque, etre telle que h(a) .h(b) # h(a;b), h etant 
5 une fonction de Hashing publique, a resultat dans 
Ze. 

E : mentionnee plus bas, est la fonction "partie en- 
tiere". 

r - E(c'+u/e) vaut done 0 ou 1. 

10 

Tous les calculs avec des exponentiations sont faits 
modulo n. 

Comme represents sur la figure 5, on peut utiliser 
le schema GQ avec valeur d'authentificatton v = (g 

15 (m))i/e. 

La verification du cheque (y', t', a, m) se fait par : 
calcul de I = g(m) ; c' = h(a, t', idA) ; verification que y'® 
= t'|c'. 

Par contre, le probleme resolu dans le procede de 
20 I'invention concerne la remise d'informations I que I'uti- 
lisateur achete au serveur d'application. Dans une tran- 
saction telematique, ou les relations entre partenaires 
sont depersonnalisees (rendues anonymes grace aux 
protocoles precedemment decrits), et effectuees par 
25 des machines dont le comportement peut a priori etre 
modifie, II faut s'assurer que la malversation qui consiste 
pour I'utilisateur a ne pas payer la prestation que lui a 
dSlivre un serveur d'application, ou pour un serveur 
d'application k ne pas dSlivrer la prestation pour laquelle 
30 I'utilisateur I'a paye, n'est pas possible. 

Deux variantes de invention sont proposees : la 
premiere variante est la plus "naturelle", et necessite les 
memes echanges que decrit precedemment, au vu de 
la figure 3 ; la deuxieme variante separe les echanges 
35 concernant le paiement et la remise d'informations. 
On utilise alors les notations suivantes : 

Sk/Pk, Sa/Pa : cles secretes et publiques du kios- 
que et du serveur d'application ; les cles publiques 
40 sont connues de tous, ce qui permet les verifica- 
tions de signatures ; 

I : information servie par le serveur d'application a 
I'utilisateur ; 
r : I chiffre par r ; 
45 . r : cle de chiffrement ; et 

r* : cte de chiffrement chiffree par Pk : r' = Pk(r). 

Dans la premiere variante, illustrSe k la figure 6, in- 
formation I envoyee par un serveur d'application a un 
50 utilisateur est chiffree et done inexploitable tant que I'uti- 
lisateur n'a pas la cle. La cle de dechiffrement est cal- 
culee par le kiosque lors du debit du compte de I'utilisa- 
teur, et renvoyee a I'utilisateur. Le serveur d'application 
signe ce qu'il envoie a I'utilisateur de fagon k ne pouvoir 
55 repudier son envoi (pour etre paye par I'utilisateur sans 
lui fournir de service, e'est-a-dire sans lui envoyer une 
information I utillsable), et k protSger I'integrite de ce 
qu'il envoie (pour eviter que I'utilisateur n'altere I'infor- 
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mation I dans I'intention de se faire rembourser). Le 
kiosque est le "juge" qui en cas de litige, dispose des 
elennents cryptograph iques irrefutables lui permettant 
de savoir qui est le fautif. 

On peut alors considerer plusieurs scenarios de 
fraudes. 

Si le serveur d'application ne veut pas servir 
i'utilisateur : . 

le serveur d'application triche sur sa signature : I'uti- 
lisateur peut verifier Sa(r, r*, c',m). Si la verification 
est negative, la transaction doit etre arretee ; 
le serveur d'application friche sur le contenu de I'in- 
formation 1 envoyee : Sa (!', r', c', m) authentifie les 
informations 1', r', c', m ; I'utilisateur peut se retour- 
ner vers le kiosque qui, avec r, est convaincu que 
rinfornnation renvoyee par le serveur d'application 
est inutilisable. 

Si I'utilisateur ne veut pas payer le serveur 
d'application : 

rutilisateur peut clianger le montant demande au 
kiosque. II dennande m1 au lieu de m, nn1<m; le 
serveur d'application peut s'en apercevoir et se 
pialndre au kiosque ; avec r', le kiosque retrouve 
ridentit6 de I'utilisateur (idU) ; et rutilisateur ne peut 
montrer au kiosque une signature Sa(r/,c',m1) 
puisqu'il a regu Sa(r,r',c'm) ; 
rutilisateur peut ne pas demander ce cheque au 
kiosque : il n'a pas r qui lui permet de transformer 1' 
en I ; 

rutilisateur peut ne pas renvoyer sig(m,c'). au ser- 
veur d'application. Mais le compte de I'utilisateur a 
deja ete debite de m. Done ce n'est pas une fraude 
interessante pour I'utilisateur. Le serveur d'applica- 
tion connait c', r* et r ; il se plaint aupr6s du kiosque 
qui, avec r' retrouve I'identite de I'utilisateur (idU), 
et c. Le kiosque retrouve done tout ce qu'il avail ren- 
voye a I'utilisateur ; I'utilisateur est done confondu. 

Si le serveur d'application repudie le paiement 
regu : 

le serveur d'application doit apporter comme preu- 
ve au kiosque : c' et r*. Avec r*, si le kiosque retrouve 
IdU, I'utilisateur a bien paye le serveur d'application. 
Si le kiosque ne retrouve pas IdU, les preuves ap- 
portees par le serveur d'application sont fausses. 

L'anonymat obten u dans le cas de cette variante est 
conditionne au fait qu'il n'y ait pas collusion entre le ser- 
veur d'application et le kiosque pour retrouver I'utilisa- 
teur. Cette hypothese est necessaire pour pouvoir trailer 
les cas de fraudes d6crils ci-dessus. 

Si Ton consid^re alors la seconde variante, illustr^e 
^ la figure 7 : la remise par le serveur d'application d'in- 
formations I a I'utilisateur se fait apres reception du che- 
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que de I'utilisateur ; ceci resout tous les cas de fraudes 
de I'utilisateur. Le serveur d'application s'engage sur Tin- 
formation qu'il va fournir a I'utilisateur apres le paiement, 
par une signature Sa{l,c',m). 
5 Si le serveur d'application triche (incoherence entre 
la signature Sa donnee et I regu, ou non remise par le 
serveur d'application de I) I'utilisateur peut se retourner 
vers le kiosque en donnant comme Elements de preuve 
de sa bonne foi le cheque m. c\ c et Sa(l,m,c'). 
10 Si I'utilisateur triche, il n'y a pas de risques pour le 
serveur d'application car il ne delivre I qu'apres verifica- 
tion du paiement. 



1 . Proced6 de paiement, dans une application telema- 
tique, de sommes dues par un utilisateur pour des 
prestations delivrees par un serveur d'application, 

20 caracterise en ce qu'il comprend les etapes 
suivantes : 

ledit serveur d'application envoie audit utilisa- 
teur une demande de paiement pour une som- 
25 me determinee (11); 

ledit utilisateur demande k un serveur de paie- 
ment, ou kiosque, donne le paiement de ladite 
somme determinee (12) ; 
ledit serveur de paiement debite le compte du- 
50 dit utilisateur de ladite somme determinee, et 

envoie audit utilisateur un cheque electronique 
correspondant a la somme determinee (13); 
ledit utilisateur verifie ce cheque electronique, 
le modifie pour que le serveur de paiement ne 
35 le reconnaisse pas, et I'envoie audit serveur 

d'application (14) ; 

ledit serveur d'application verifie ce cheque 
electronique et stocke celui-ci (15) ; et en ce 
que, dans des etapes ulterieures : 
40 - ledit serveur d'application transmet audit ser- 
veur de paiement au moins un cheque electro- 
nique stocke (16) ; 

ledit serveur de paiement verifie chacun des 
cheques electroniques regus et paye audit ser- 
^5 veur d'application le montant cumule de ceux- 

ci (17). 

2. Proced6 selon la revendication 1 , caracterise en ce 
qu'un cheque designe un ensemble de donnees 

50 electroniques emises par le kiosque, comprend une 
signature electronique et a une valeur determinee. 

3. Procede selon la revendication 2, caracterise en ce 
qu'un cheque contient une information concernant 

55 son montant, sa date, ainsi qu'un alea. 

4. Proced6 selon la revendication 1 , caracterise en ce 
que la verification de la septieme etape (17) con- 
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cerne la signature des cheques, la non-presence 
d'un cheque identique dans le fichier des cheques 
regus et la mise a jour de ce fichier. 

Precede selon la revendlcation 1 , caracterlse en ce 5 
que, malgre les traitements prealables, les cheques 
regus apr^s I'etape de transmission d'au moins un 
cheque 6lectronique, stocke par te serveur d'appli- 
cation, au serveur de paiennent ne peuvent etre cor- 
ret6s avec ceux envoyes dans I'etape d'envoi d'un io 
cheque electronique par le serveur de paiement a 
I'utilisateur, grace a la modification de I'etape d'en- 
voi du cheque au serveur d'application, ce qui per- 
met de garder I'anonymat de I'utilisateur. 

15 

Procede seton la revendication 1 , caracterlse en ce 
que les serveurs d'application collectent leurs che- 
ques avec une certaine periodiclte. 

Procede selon I'une quelconque des revendlcations 20 
precedentes, caracterlse en ce qu'il permet de re- 
soudre les litiges eventuels entre paiement et remi- 
se de I'information electronique, selon deux 
moyens, et ceci bien que I'anonymat soit une ca- 
racteristique importante d'un tel procede : 25 

information envoyee par le serveur d'applica- 
tion (A) k I'utilisateur (U) peut etre chiffree, la 
cle de dechiffrement est calcul^e par le kiosque 
(K) lors du debit du compte de Tutillsateur (U) 30 
et renvoyeearutilisateur(U), et lesen/eurd'ap- 
plication (A) signe ce qu'it envoie a I'utilisateur 
(U), ainsi paiement et remise sont 
synchronises ; 

la remise par le serveur d'application (A) des 35 
informations (I) ^ I'utilisateur (U) se fait apres 
reception du cheque de I'utilisateur (U), mais le 
serveur s'engageant avant le paiement sur la 
remise de information, par une signature elec- 
tronique. 

Disposltif de mise en oeuvre du procede selon I'une 
quelconque des revendications 1 a 7, caracterise 
en ce qu'il comprend au moins un kiosque (K), au 
moins un serveur d'application (A) en liaison avec 45 
au moins un utilisateur (U) par Tintermediaire d'un 
reseau de communication, les techniques de signa- 
ture aveugle permettant de laisser apparentes dans 
les informations signees le montant et la date, et 
amenant une simplification importante par rapport 50 
aux techniques habituelles. 
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LE SERVEUR D'APPLICATION ENVOIE 
A L'UTiLISATEUR UNE DEMANDE DE PAIEMENT 
POUR UNE SOMME DETERMINEE 




' ■ , 


L'UTILISATEUR 
SERVEUR DE PAiEMEN 
DE U\DITE SOMf\ 


DEMANDE A UN 

r DONNE LE PAIEMENT 

;1E DETERMINEE 



LE SERVEUR DE PAIEMENT DEBITE LE COMPTE DUDiT 
UTILISATEUR DE LADITE SOMME DETERMINEE. ET 
LUI ENVOIE UN CHEQUE ELECTRONIQUE 
CORRESPONDANT A UK SOMME DETERMINEE 



L'UTILISATEUR VERIFIE CE CHEQUE ELECTRONIQUE 
ET UENVOIE AU SERVEUR D'APPLICATION 



i 

LE SERVEUR D'APPLICATION VERIFIE CE CHEQUE 
ELECTRONIQUE ET STOCKE CELUI-CI 




LE SERVEUR D'APPLICATION TRANSMET 
AU SERVEUR DE PAIEMENT AU MOINS UN 
CHEQUE ELECTRONIQUE STOCKE 



LE SERVEUR DE PAIEMENT VERIFIE CHACUN DES 
CHEQUES ELECTRONIQUES RECUS 
ET PA YE AUDIT SERVEUR D'APPLICATION LE 
MONTANT CUMULE DE CEUX-CI 
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VERIFIE sig{m.c) 
CALCULE sig(m,c') 
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SERVEUR 
KD'APPLICATION** 
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CHOIX ALEA c' 
m=MONTANT/DATE 



VERIFIE sig(m.c') 
STOCKE CHEQUE 
[m,c\ sig(m,0] 



FIG. 3 
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P = Pi P2 
x:RANDOM 



y = X + sc MOD q 
DEBiTE COMPTE 
DE L'UTILISATEUR 
DE m F 



m,i 



• UTILISATEUR • 



SI UTILISATEUR 
D* ACCORD : 
EMISSION 



1 



I 



P=prp2 

ALEAS u.v DANS Zq 
t* = tbV 



c = c'+u MOD q 



VERIFIE 
b^ = tp^ 

y* = y + vMODq 



m 



C' 



SERVEUR 
"D'APPLICATION 



m = MONTANT A 
DEMANDER A 
L'UTILISATEUR 



_ m _ 

P = Pl P2 



a : ALEA 
c' = h(a.t'.idA) 



VERIFIE QUE 
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MEMORISE LE 
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(y'.t'.a.m) 



FIG. 4 
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^p,q SECRETS^ 
,e.n PUBLICS j 



l = g(m) 

ALEA X, 0 < x<n 



m, idn 



y = xV*^ 

DEBITE COMPTE 
DE L'UTILISATEUR 
DEm F 



UTILISATEUR- 
(e.n) 



SI UTILISATEUR 
D*ACCORD : 
I = g(m) 



ALEA w,0<w<n 
ALEA u,0<u<e 



c = c' + u MOD e 
r = E(c' + u/e) 



VERIFIE 
y ^ = tl^ 

y' = wyr 



FIG. 5 
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a : ALEA 
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MEMORISE LE 
CHEQUE 
(y'.f.a.m) 
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KIOSQUE 



UTILISATEUR 



DEBITE COMPTE 
DE LUTILISATEUR 
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CALCULE sig(m.c) 
CALCULE r = Sk(0 
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I : INFORMATION A 
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VERIFIE Sa(l*/.C'.m) 
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m.c' 
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r sig(m,c) 
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VERIFIE sig(m.c) 
CALCULE sig(m.c*) 



sig(m,c') 



VERIFIE sig(m,c*) 
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[m,c',sig(m,c*)] 
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sig(nn.c') 
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